home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19951130-19960209 / 000323_news@columbia.edu _Mon Jan 22 14:48:03 1996.msg < prev    next >
Internet Message Format  |  2020-01-01  |  3KB
  1. Return-Path: news@columbia.edu
  2. Received: from apakabar.cc.columbia.edu (apakabar.cc.columbia.edu [128.59.35.159]) by watsun.cc.columbia.edu (8.7.3/8.7.3) with ESMTP id OAA29679 for <kermit.misc@watsun>; Mon, 22 Jan 1996 14:48:00 -0500 (EST)
  3. Received: (from news@localhost) by apakabar.cc.columbia.edu (8.7.3/8.7.3) id OAA28512 for kermit.misc@watsun; Mon, 22 Jan 1996 14:47:52 -0500 (EST)
  4. Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
  5. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  6. Newsgroups: comp.protocols.kermit.misc
  7. Subject: Re: Dr. Dobb's
  8. Date: 22 Jan 1996 19:47:21 GMT
  9. Organization: Columbia University
  10. Lines: 42
  11. Message-ID: <4e0pk9$rqi@apakabar.cc.columbia.edu>
  12. References: <4drisb$bnb@freenet.unbc.edu>
  13. NNTP-Posting-Host: watsun.cc.columbia.edu
  14.  
  15. In article <4drisb$bnb@freenet.unbc.edu>,
  16. Jack Bowling <ad151@freenet.unbc.edu> wrote:
  17. > Nice to see the good Kermit press in the latest Dr. Dobb's Journal. My 
  18. > assumption is that the techniques described by the author therein are his 
  19. > own alterations to the Kermit source code? Or are they already contained 
  20. > in one of the many flavors of Kermit?
  21. >
  22. Tim Kientzle wrote a book called "The Working Programmer's Guide to Serial
  23. Protocols" and he wrote his own Kermit and XYZMODEM code from scratch.
  24. The Dr Dobbs article is a followup.
  25.  
  26. The Kermit protocol was designed from the very beginning to (a) be
  27. extensible, and (b) allow sliding windows with selective retransmission.
  28.  
  29. There is a difference between an abstract protocol specification and its
  30. implementation in software.  The major performance issue in a sliding
  31. window protocol with selective retransmission is error recovery.  There
  32. are many sorts of errors, and many possible ways to recover from each.
  33. "Which packet(s) should I retransmit?" and so on.  These are not protocol
  34. issues, but implementation ones.
  35.  
  36. The techniques used in MS-DOS Kermit and C-Kermit have proven effective
  37. and stable in the real world for some years.  As Tim points out, Kermit
  38. sliding-window transfers degrade quite slowly under conditions of
  39. increasing noise and/or delay.  This is by design, and we verified it
  40. ourselves in the lab some years ago under controlled conditions.  This is
  41. not to say that other strategies are not possible or that our own cannot
  42. be improved.  But I think the important point is that the error recovery
  43. methods used in MS-DOS Kermit and C-Kermit have been tested by millions
  44. over a broad range of connections and platforms, and whenever a situation
  45. arose that we did not handle well (or at all), we refined our techniques
  46. accordingly, and this has resulted in a stable base of code that works
  47. well in practically every situation.
  48.  
  49. As new bottlenecks become evident, we will continue to address them, but
  50. by now I think most such advances in this area will qualify as "fine
  51. tuning" rather than "great leaps forward".
  52.  
  53. In the meantime, thanks to Tim for publicizing some of the
  54. little-understood benefits of the Kermit protocol.
  55.  
  56. - Frank